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(57) ABSTRACT 

Techniques for performing static binding of dispatched-calls 
in the presence of dynamic linking and loading are provided. 
A method for increasing the execution performance of a 
function at run-time includes compiling the function, which 
may either be interpreted or previously compiled, and iden- 
tifying a call within the function to a process. The method 
also includes adding dependency information to the func- 
tion. The dependency information is arranged to indicate a 
status of the function, and contains information pertaining to 
the class, the name, and the signature associated with the 
process. In one embodiment, the process is a virtual process, 
and the method includes analyzing a class structure associ- 
ated with the function in order to determine when the virtual 
process is a substantially unique target of the call. In such an 
embodiment, the virtual process may be inlined into the 
function when it is determined that the virtual process is the 
substantially unique target of the call. 
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STATIC BINDING OF DYNAMICALLY- Furthermore, the test function may be compiled at runt- 

DIS PATCH ED CALLS IN THE PRESENCE OF tow to increase performance. At runtime compilation, it is 

DYNAMIC LINKING AND LOADING possible that only classes A 3 and B 5 are loaded. 

Accordingly, it appears from inspection of the loaded classes 

CROSS REFERENCE TO RELATED 5 that one may assume that the message x,foo( ) will only 

APPLICATION invoke A::foo( ). Of course, if during runtime execution 

class C 7 is loaded, this assumption would prove to be false. 

This application claims priority of provisional U.S. patent 

application Ser. No. 60/079,765, filed Mar. 24, 1998, which SUMMARY OF THE INVENTION 

is incorporated herein by reference in its entirety for all In general, embodiments of the present invention provide 

purposes. 10 innovative techniques for performing static binding of 

dispatched -calls in the presence of dynamic linking and 

BACKGROUND OF THE INVENTION loading. As a method is being compiled at runtime, 

Hie present invention relates to runtime compilation of dynamically-dispatched calls are identified. The current 

software. More specifically, the invention relates to tech- c £ lass * ana 1 ^ zed to determine how the calls may 

niques for performing static binding of dynamically- 15 be -«P^ized. The calb imay be .optimized and dependency 

dispatched calls in the presence of dynamic linking and ^orma ion may be added to the compiled method so that 

loadine when classes are loaded at runtime execution, it can be 

_ ' , ......... . . * . determined if the compiled method is still valid, should be 

Hie fundamental idea behind object-oriented languages is intcr p re tcd (e.g., deoptimized), or recompiled (e.g., 

the combination of both data and the methods (or functions) reoptimized) 

that operate on that data into a single unit, which is called an 20 A „ ,. _ _ _ . r . • r „ 

.» , a u- c . n >j , According to one aspect or the present invention, a 

object. An object s functions typically provide the only way . € r • ,u c c ? 

t J .1 j , .1 t • J \ „ / . rp». * / method for increasing the execution performance of a func- 

to access the data that is encapsulated by the object. The data , . , % .,. c ... 

. , r tion at run-time includes compiling the function, which may 

is accessed by sending a message to the object instructing ... , . t 4 , • 1 1 j J j .-r ■ 

tl _ .... 1 *l .i_ j c a. . . & either be interpreted or previously complied, and identifying 

tne oDject to invoice tne metnoa specinea oy tne message. a caU wimin the 

to a process. The method also 

Efficient message dispatch is of paramount importance in inc i ud es adding dependency information to the function, 

object-oriented languages. This is because message dispatch ^ dependency information is arranged to indicate a status 

is a very frequent operation in objectnonented programs and of the functionf and contains information pertaining to the 

is performed at runtime; therefore, it should be as fast as class> the namCi ^ the s i gaalure associated with the 

possible. Message dispatch, however, is far from being a process 

trivial operation. Unlike procedural programming languages 30 , n 0M embodiment the process fa , virtual ocess and 

(eg., the C programming language) that can determine a , he me(hod indudes ana , £ a c , ass slm ^ 

function s address before runtime object-oriented lan- whh me ^ order t0 6 determine when the virtual 

guages must determine the method that handles a message ^ fa a substantially unique target of the ca „. In sucn an 

that has been dispatched to a receiver object dynamically at £ mbodiment) tne p^cess may be inlined into the 

runtime, and it may involve an extensive search. 35 h DClioD when it is determined that the virtual process is the 

In order to better understand the complexities of message substantially unique target of the call. Alternatively, in such 

dispatch, an example of a class hierarchy will be described. an embodiment, a direct call to the virtual process may be 

FIG. 1 shows a class hierarchy including methods of each placed in the function 

I 1 T u d fl hierarCby 1 faC , 1U / leS M itS ^ \ Pi Tl According to another aspect of the present invention, a 
A3 that defines two virtual functions foo( ) and bar( ). „, ^p^.^p^^ method for analyzing a first class 
Virtual functions are functions that may be denned in a r . . . r, . , f . . ■ 
parent class and redefined in associated I children classes. plated with a class ^hierarchy of ^a system durmg run-time 
Classes B 5 and class C 7 inherently include the data and 1 " c,udes raarkin S ^e first class and marking a second class 
methods of the parent class A3. As shown, class B 5 does that 1S a su P erclass of lhe firsl class t0 indlcate an associated 
not redefine either of the virtual functions foo( ) and bar( ). between the two class. A compiled function associated with 
However, class C 7 redefines the virtual function foo( ). 45 the system is then inspected. The compiled function includes 
When an object of class C 7 is requested to invoke the dependency information that is arranged to indicate a valid- 
method foo( ), the method invoked will be the method ity status of the compiled function as well as the optimiza- 
defined by the class C 7, not the method defined in the parent tion status of the compiled function. Inspecting the compiled 
class A3. Classes D 9 and E 11 also redefine the method foo( function includes determining when at least one of the first 
). 50 class and the second class is identified in the dependency 
As it is generally impossible to determine the class of an information. When it is determined that either the first class 
object statically, the search for the correct method associated or both the first class and the second class is identified in the 
with the object is performed during runtime execution or, dependency information, a determination is made regarding 
more specifically, during message dispatch. For example, whether the compiled function is invalid. In one 
assume a method is as follows: 55 embodiment, the method may include de-optimizing the 

compiled function when it is determined that the compiled 
function is invalid. De-optimizing the compiled function 

tcst ^ may return the function to an interpreted state. 

{ Other features and advantages of the invention will 

60 become readily apparent upon review of the following 

xfoo O; detailed description in association with the accompanying 



} 



drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 



If all of classes A-E are loaded at runtime execution, the 65 The present invention, in specific embodiments, may be 
determination of which function foo( ) to call will depend on understood by reference to the following description taken 
which class x is an instance. in conjunction with the accompanying drawings in which: 
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FIG. 1 illustrates a class hierarchy of classes including called a "class file" that includes bytecodes for methods of 

virtual functions in an object-oriented environment. a class. In addition to the bytecodes for methods of a class, 

FIG. 2 illustrates an example of a computer system that the class file includes a symbol table as well as other 

may be utilized to execute the software of an embodiment of ancillary information. 

the invention. 5 A computer program embodied as Java bytecodes in one 

FIG. 3 shows a system block diagram of the computer °r more class files is platform independent. The computer 

system of FIG. 1. program may be executed, unmodified, on any computer that 

FIG. 4 is a diagrammatic representation of a virtual able to run an uiiplementation of the Java virtual machine, 

machine in accordance with an embodiment of the present in ^ Jav * machine 15 a s?^™ emulator of a 

invention generic computer that is a major factor in allowing com- 

™„ -' .„ „ * , , puter programs for the Java virtual machine to be platform 

FIG. 5 illustrates a flowchart of an embodiment of the fndeDendent 

invention that compiles a method at runtime. J[ ' . 

, , ... „ . t . The Java virtual machine may be implemented as a 

FIG. 6 shows an embodiment of a compiled method SQ&wm ml ter Conventional interpreters decode and 

including dependency ^formation, is execute me machme mstructions of aQ interpre ted 

FIG. 7 illustrates a flowchart of a process of class loading program one instruction at a time during execution, which is 

during runtime execution in accordance with an embodiment m contrast to compilers that decode source code into native 

of the present invention. machine instructions prior to execution so that decoding is 

FIG. 8 shows a representation of a class hierarchy in not performed during execution. The Java virtual machine 

memory in accordance with an embodiment of the present 20 may include both an interpreter and compiler for runtime 

invention. compilation. Typically, the Java virtual machine will be 

written in a programming language other than the Java 

DETAILED DESCRIPTION OF PREFERRED programming language (e.g., the C++ programming 

EMBODIMENTS language). 

Definitions ^ FIG. 2 illustrates an example of a computer system that 

may be used to execute the software of an embodiment of 

Machine instruction (or instruction) — An instruction that the invention. FIG. 2 shows a computer system 301 that 

directs a computing device to perform an operation specified includes a display 303, screen 305, cabinet 307, keyboard 

by an operation code (OP code) and optionally one or more 3Q 309, and mouse 311. Mouse 311 may have one or more 

operands. buttons for interacting with a graphical user interface. Cabi- 

Virtual machine instruction— An instruction for a soft- net 307 houses a CD-ROM drive 313, system memory and 

ware emulated microprocessor or computer architecture a nard drive (see FIG. 3) which may be utilized to store and 

(also called virtual code). retrieve software programs incorporating computer code 

Native machine instruction-An instruction that is 35 ! hat im P lemem _ s the invention, data for use with the 

designed for a specific microprocessor or computer archi- invention, and the like. Although the CD-ROM 315 is shown 

lecture (also called native code). as an exemplary computer readable storage medium, other 

w , J4r , y „ , computer readable storage media including floppy disk, 

Method — A software routine (also called a function. ♦ « i . jujj- u 

. v r . * * tape, flash memory, system memory, and hard dnve may be 

subroutine, procedure, and member function). # . r . n A , , . j ^ • 

v ' ' utilized. Additionally, a data signal embodied m a earner 

Runtime compilation— Compilation of code that is per- wave (e.g., in a network including the Internet) may be the 

formed at runtime. computer readable storage medium. 

Runtime execution — Execution of code that is performed FIG. 3 shows a system block diagram of computer system 

at runtime. 301 used to execute the software of an embodiment of the 

n ♦ *i j n • « invention. As in FIG. 2, computer system 301 includes 

Detailed Description 45 - M , \ , J „ 

r monitor 303 and keyboard 309, and mouse 311. Computer 

In the description that follows, the present invention will system 301 farther includes subsystems such as a central 

be described in reference to preferred embodiments that processor 351, system memory 353, fixed storage 355 (e.g., 

statically bind dynamically-dispatched calls in Java virtual hard drive), removable storage 357 (e.g., CD-ROM drive), 

machine instructions (or bytecodes). However, the invention 50 display adapter 359, sound card 361, speakers 363, and 

is not limited to any particular language, computer network interface 365. Other computer systems suitable for 

architecture, or specific implementation. Therefore, the use with the invention may include additional or fewer 

description of the embodiments that follow is for purposes subsystems. For example, another computer system could 

of illustration and not limitation. include more than one processor 351 (i.e., a multi-processor 

The Java™ programming language is an object-oriented 55 system), or a cache memory, 

high level programming language developed by Sun Micro- The system bus architecture of computer system 301 is 

systems and designed to be portable enough to be executed represented by arrows 367. However, these arrows are 

on a wide range of computers ranging from small devices illustrative of any interconnection scheme serving to link the 

(e.g., pagers, cell phones and smart cards) up to supercom- subsystems. For example, a local bus could be utilized to 

puters. Computer programs written in Java (and other 60 connect the central processor to the system memory and 

languages) may be compiled into virtual machine instruc- display adapter. Computer system 301 shown in FIG. 3 is but 

lions for execution by a Java virtual machine. In general the an example of a computer system suitable for use with the 

Java virtual machine is an interpreter that decodes and invention. Other computer architectures having different 

executes the virtual machine instructions. configurations of subsystems may also be utilized. 

The virtual machine instructions for the Java virtual 65 Typically, computer programs written in the Java pro- 
machine are bytecodes, meaning they include one or more gramming language are compiled into bytecodes or Java 
bytes. The bytecodes are stored in a particular file format virtual machine instructions that are then executed by a Java 
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virtual machine. The bytecodes are stored in class files that constructing from the binary form a Class object to represent 

are input into the Java virtual machine for execution. A the class. The Class class is a class for storing or represent- 

virtual machine may execute on a computer system such as ing the structures of classes. Linking is the process of taking 

the computer system discussed previously with respect to . a binary form of the class and combining it into the runtime 

FIGS. 2 and 3. FIG. 4 is a diagrammatic representation of a 5 state of the system so that it may be executed. Initialization 

virtual machine which is supported by computer system 301 of a class includes executing the class' static initializers and 

of FIGS. 2 and 3, and is suitable for implementing the initializers for static fields declared in the class, 

present invention. When a computer program, e.g., a com- Each Java class has a constant pool associated with it. The 

puter program written in the Java™ programming language, constant pool is stored in the Java class file and serves a 

is executed, source code 410 is provided to a compiler 420 10 function similar to symbol tables. Typically, each entry in 

within compile-time environment 405. Compiler 420 trans- the constant pool is indexed by a number starting with one 

lates source code 410 into bytecodes 430. In general, source and ending with the number of entries in the constant pool, 

code 410 is translated into bytecodes 430 at the time source A method for a class accesses entries in the constant pool by 

code 410 is created by a software developer. the index and a method for one class may not access a 

Bytecodes 430 may generally be reproduced, 15 constant pool for another class, 
downloaded, or otherwise distributed through a network, In addition to the constant pool storing literal constants, 
e.g., network interface 365 of FIG. 3, or stored on a storage the constant pool stores classes, methods, fields, and inter- 
device such as storage device 355 of FIG. 3. In the described faces symbolically. By storing these entries symbolically it 
embodiment, bytecodes 430 are platform independent. That is meant that the name identifying the entry is stored, not the 
is, bytecodes 430 may be executed on substantially any 20 physical address. In other words, if a class A has a field F, 
computer system that is running on a suitable virtual both the names of A and F (along with a type signature for 
machine 440. F) may be stored in the constant pool. By storing names and 

Bytecodes 430 are provided to a runtime environment 435 not address, the Java runtime system resolves the symbolic 

which includes virtual machine 440. In one embodiment, the reference into a physical address dynamically at runtime, 

virtual machine may be a Java™ virtual machine. Runtime 25 FIG. 5 illustrates a flowchart of an embodiment of the 

environment 435 may generally be executed using a pro- invention that compiles a method at runtime. At a step 501, 

cesser or processors such as processor 351 of FIG. 3. Virtual the system determines that it is beneficial to compile a 

machine 440 includes a compiler 442, an interpreter 444, method. In general, compiling a method increases the execu- 

and a runtime system 446. Bytecodes 430 may be provided tion performance of the method. However, there are many 

either to compiler 442 or interpreter 444. 30 instances where methods are not compiled. By way of 

When bytecodes 430 are provided to compiler 442, meth- example, compiled methods may require more storage space 

ods contained in bytecodes 430 are compiled into machine than methods which are not compiled. In any event, once it 

instructions. In one embodiment, compiler 442 is a just-in- is determined that a particular method should be compiled, 

time compiler which delays the compilation of methods 35 that method is compiled at a step 503. 

contained in bytecodes 430 until the methods are about to be At a step 505, the system identifies a call to a virtual 

executed. When bytecodes 430 are provided to interpreter function in the method that is being compiled. As discussed 

444, bytecodes 430 are read into interpreter 444 one byte- above, resolution of a virtual function call is done dynami- 

code at a time. Interpreter 444 then performs the operation cally at runtime. In the Java virtual machine instructions, the 

defined by each bytecode as each bytecode is read into 4Q call is an invokevirlual instruction. 

interpreter 444. That is, interpreter 444 "interprets" byte- The system analyzes the class hierarchy at run-time 

codes 430, as will be appreciated by those skilled in the art. compilation at a step 507. The class hierarchy may indicate 

In general, interpreter 444 processes bytecodes 430 and t h at currently only one function of a loaded class would be 

performs operations associated with bytecodes 430 substan- the recipient of the virtual function call. If only one function 

tially continuously. 45 0 f the loaded class would be the recipient of the virtual 

When a method is invoked by another method, or is function call, the system may place a direct call to that 

invoked from runtime environment 435, if the method is function in the compiled method. Additionally, the system 

interpreted, runtime system 446 may obtain the method from may inline the whole function into the compiled method, 

runtime environment 435 in the form of a sequence of Inlining the whole function requires more storage space for 

bytecodes 430, which may be directly executed by inter- 50 the compiled method, but results in a faster performance, 

preter 444. If, on the other hand, the method which is In some cases, there is more than one function of loaded 

invoked is a compiled method which has not been compiled, classes that could be the recipient of the virtual function call, 

runtime system 446 also obtains the method from runtime If such is the case, the system may inline a decision tree or 

environment 435 in the form of a sequence of bytecodes hash table that includes direct calls to the functions and/or 

430, then may go on to activate compiler 442. Compiler 442 55 inline functions. That is, the call to the virtual function as 

then generates machine instructions from bytecodes 430, discussed with respect to step 505 may be optimized at a step 

and the resulting machine -language instructions may be 909. Techniques for performing virtual function calls are 

executed directly by processor 351 of FIG. 3. In general, the described in application Ser. No. 08/944,332, filed Oct. 6, 

machine-language instructions are discarded when virtual 1997, which is hereby incorporated by reference for all 

machine 440 terminates. The operation of virtual machines 60 purposes. 

or, more particularly, Java™ virtual machines, is described A t a step 511, the system adds dependency information to 

in more detail in The Java™ Virtual Machine Specification tne compiled method. The dependency information may 

by Tim Lindholm and Frank Yellin (ISBN 0-201 -63452-X), include the class, function name, and signature (i.e., param- 

which is incorporated herein by reference. eter lypes ) Q f eacn virlual function that has been optimized 

Java classes (and interfaces) are dynamically loaded, 65 at step 509. In this manner, when classes are loaded at 

linked and initialized. Loading is the process of the system runtime execution, the dependency information may be 

finding the binary form of the class (e.g., the class file) and checked for a compiled method to determine if the compiled 
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method is still valid, should be deoptimized, or should be Conclusion 

reoptimized. This process will be described in more detail , . . 

below with reference to FIG 7 Whlle mc above 1S a com P lete description of preferred 

FIG. 6 shows an embodiment of a compiled method with embodiments of the invention, various alternatives, 

dependency ^formation. A compiled method 609 includes a 5 modifications, and equivalents may be used. It should be 

header 603 and compiled code 605. Header 603 includes, evident that the invention is equally applicable by making 

among other things, dependency information 607. Depen- appropriate modifications to the embodiments described 

dency information 607, in the described embodiment, is a above. For example, although the embodiments described 

list of the class, the name, and the signature of all the virtual have been in reference to Java virtual machine instructions, 

function calls that were optimized in compiled method 609. 3Q the principles of the present invention may be readily 

Although this information may be stored as a simple list, a applied to other instructions. Therefore, the above descrip- 

variety of other storage techniques may be utilized. tion should not be taken as limiting the scope of the 

FIG. 7 illustrates a flowchart of a process of class loading invention, 

during runtime execution. At a step 701, the system receives What is claimed is: 

a class to be loaded at runtime. The system then marks the 1. A run-time based computer-implemented method for 
class and all of its superclasses at a step 703. The classes 1 enhancing the execution performance of a function at run- 
may be marked by setting a boolean field in a class hierarchy time, the computer-implemented method comprising: 
structure (see FIG. 8). compiling the function at run-time; 

At a step 705, the system inspects all the compiled . , + - A . „ , . „ . 

, . *\ ./ , . , v. <■ , , , identifying a call to a process at run-time, the call to the 

methods to determine if they include any of the marked u * • i j j • t 

, ...j , • r ,20 process being included in the function; 

classes in their dependency information. As discussed r ° 

above, the dependency information may be stored in a addin g dependency information to the function at run- 
header of the compiled method. If any of the marked classes Ume > wherein the dependency information is arranged 
are included in a compiled method's dependency to indicate a status of the function, the dependency 
information, the system determines if there is a function information including class information, name 
name and signature match at a step 707. 25 information, and signature information associated with. 

By determining if there is a function name and signature the P' 0 ? 655 '. ^ hercin the , * tatus , ° u f * e ftlnctio " is 

match, the system ascertains whether loading the class arranged to indicate a validity of the function and a 

causes any of the compiled methods to effectively be invali- compilation status of the function; 

dated. In other words, the determination of whether there is determining whether the compiled function is valid based 

a function name and signature match determines whether on tne dependency information; and 

loading the class generates a new, and previously unac- when it is determined that the compiled function is 

counted for, recipient for a virtual function call that has been invalid, determining at least one of whether the func- 

optimized. tion is suitable for deoptimization and whether the 

For example, referring again to FIG. 1, if only classes A 35 function is suitable for reoptimization. 
3 and B 5 are loaded at runtime compilation, the system may 2. A computer-implemented method as recited in claim 1 
place a direct call to A::foo( ) (or even inline the whole wherein the process is a virtual process, the computer- 
function) in a compiled method since there is only one implemented method further including: 
function that could be the recipient of the virtual function analyzing a class structure associated with the function, 
call. However, if during runtime execution, class C 7 is 40 wherein analyzing the class structure includes deter- 
loaded then there another possible recipient for the virtual mining when the virtual process is a substantially 
function call (i.e., C::foo( )). Thus, the compiled method unique target of the call. 

should be either deoptimized or reoptimized. Techniques for 3. A computer-implemented method as recited in claim 2, 

deoptimization of compiled methods are described in appli- the computer-implemented method further including: 

cation Sen No. 08/944,330, filed Oct. 6, 1997, which is 45 inlying the virtual process into the function when it is 

hereby incorporated by reference for all purposes. determined that the virtual process is the substantially 

If there is a match at step 707 for a compiled method, the unique target of the call, 

compiled method may be deoptimized at a step 709. Deop- 4. A computer-implemented method as recited in claim 2, 

timizing the compiled method may include reverting, or the computer-implemented method further including: 

otherwise "de -compiling," the method to its interpreted 50 placing a direct call to the virtual process in the function, 

form. Additionally, the system may reoptimize the compiled 5 A computer-implemented method as recited in claim 1 

method so that it now takes into account the newly loaded further including: 

C ^ a ^' ft , determining when the function is suitable for compilation. 

FIG. 8. shows a representation of a class hierarchy in 6 A computer-implemented method as recited in claim 1 

memory. A class 801 is shown at the root indicating it is a 55 further comprising: 

superclass to classes below it. As shown, classes 803 and . . * . . , . , . - 

one ui ri om n. i *r c loading a class that is associated with the function; 

805 are subclasses of class 801. The class information for & 

each class may include a boolean field that is used to mark determining when the function is not a substantially 

the classes as in step 703 of FIG. 7. uni ^ ue caller 10 the P rocess i ™d 

Additionally, the class information for each class may 60 de-compiling the function when it is determined that the 

include a subclass pointer and a sibling pointer. The subclass function is not a substantially unique caller to the 

pointer points to a first subclass, which in this example is process. 

class 803. The sibling pointer form a linked list of the classes 7 - A computer-implemented method as recited in claim 1 

that are siblings. As shown, the sibling pointer of class 803 further comprising: 

points to class 805. Utilizing the subclass and sibling 65 loading a class that is associated with the function; 

pointers, the system in an embodiment of the invention is determining when the function is not a substantially 

able to easily traverse the class hierarchy. unique caller to the process; and 
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re -compiling the function when it is determined that the 
function is not a substantially unique caller to the 
process. 

8. A computer-implemented method as recited in claim 1 
further including: 5 

loading a class, the class being associated with the func- 
tion. 

9. A computer-implemented method as recited in claim 1, 
further including: 

loading a class, wherein the class is potentially associated 10 
with the compiled function. 

10. A run-time based computer- implemented method for 
enhancing the execution performance of a function at run- 
time, the computer- implemented method comprising: 

compiling the function at run-time; 

identifying a call to a process at run-time, the call to the 
process being included in the function; 

adding dependency information to the function at run- 
time, wherein the dependency information is arranged 2 n 
to indicate a status of the function, the dependency 
information including class information, name 
information, and signature information associated with 
the process, wherein the status of the function is 
arranged to indicate a validity of the function and a 2 s 
compilation status of the function; 

loading a class, wherein the class is potentially associated 
with the compiled function; 

determining whether the compiled version of the function 
remains valid after the class is loaded, based on the 30 
dependency information; and 

when it is determined that the compiled version of the 
function is invalid, determining at least one of whether 
the function is suitable for deoptimization and whether 
the function is suitable for reoptimization. 35 

11. A run-time based computer-implemented method for 
analyzing a first class associated with a class hierarchy of a 
system during run-time, the computer-implemented method 
comprising: 

marking the first class during run-time; 40 

marking a second class during run-time, the second class 
being included in the class hierarchy, the second class 
further being associated with the first class, wherein 
marking the second class substantially identifies the 
second class as being associated with the first class; 

inspecting a compiled function associated with the system 
during run-time, the compiled function including 
dependency information, the dependency information 
being arranged to indicate a validity status of the 5Q 
compiled function and the optimization status of the 
compiled function, wherein inspecting the compiled 
function includes determining when at least one of the 
first class and the second class is identified in the 
dependency information; 5S 

determining when the compiled function is invalid when 
it is determined that at least one of the first class and the 
second class is identified in the dependency informa- 
tion; and 

when it is determined that the optimization status of the 60 
compiled function is invalid, determining at least one 
of whether the function is suitable for deoptimization 
and whether the function is suitable for reoptimization. 

12. A computer- implemented method as recited in claim 

11 further including: 65 
de -compiling the compiled function when it is determined 
that the compiled function is invalid, wherein 



de -compiling the compiled function effectively places 
the compiled function in an interpreted form. 

13. A computer-implemented method as recited in claim 
11 further including: 

re-compiling the compiled function when it is determined 
that the compiled function is invalid, wherein 
re-compiling the compiled function allows the com- 
piled function to account for the first class. 

14. A computing system suitable for enhancing the execu- 
tion performance of a function at run -time, the computing 
system comprising: 

a processor; 

a compiler arranged to compile the function at run-time; 
a call identifier arranged to identify a call to a process at 
run-time, the call to the process being included in the 
function; and 
a mechanism suitable for: 
adding dependency information to the function at run- 
time, wherein the dependency information is 
arranged to indicate a status of the function, the 
status being arranged to include a validity status of 
the function; 

determining whether the compiled function is valid 
based on the dependency information; and 

when it is determined that the compiled the function is 
invalid, determining at least one of whether the 
function is suitable for deoptimization and whether 
the function is suitable for reoptimization. 

15. A computing system as recited in claim 14, wherein 
the process is a virtual process, the computing system further 
including: 

an analyzer for analyzing a class structure associated with 
the function, wherein analyzing the class structure 
includes determining when the virtual process is a 
substantially unique target of the call. 

16. A computing system as recited in claim 15, the 
computing system further including: 

an inliner arranged for inlining the virtual process into the 
function when it is determined that the virtual process 
is the substantially unique target of the call. 

17. A computer program product for enhancing the execu- 
tion performance of a function at run-time, the computer 
program product comprising: 

computer code that compiles the function at run-time; 
computer code that identifies a call to a process at 

run-time, the call to the process being included in the 

function; 

computer code that adds dependency information to the 
function at run-time, wherein the dependency informa- 
tion is arranged to indicate a status of the function, the 
status being arranged to include when a validity status 
of the function; 

computer code that determines whether the compiled 
function is valid based on the dependency information; 
and 

computer code that when it is determined that the com- 
piled the function is invalid determines at least one of 
whether the function is suitable for deoptimization and 
whether the function is suitable for reoptimization; 

a computer- readable medium that stores the computer 
codes. 

18. A computer program product as recited in claim 17 
wherein the process is a virtual process, the computer 
program product further including: 

computer code that analyzes a class structure associated 
with the function, wherein analyzing the class structure 
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includes determining when the virtual process is a 
substantially unique target of the call. 

19. A computer program product as recited in claim 18, 
further including: 

computer code that inlines the virtual process into the 5 
function when it is determined that the virtual process 
is the substantially unique target of the call. 

20. A computer program product as recited in claim 18, 
the computer program product further including: 

computer code that places a direct call to the virtual 10 
process in the function. 

21. A computer program product as recited in claim 17, 
further including: 

computer code that determines when the function is 35 
suitable for compilation. 

22. A computer program product as recited in claim 17 
wherein the computer-readable medium is one selected from 
the group consisting of a floppy disk, a hard disk, a tape, a 
data signal embodied in a carrier wave, a CD-ROM, a 
system memory, and a flash memory. 

23. A computer program product as recited in claim 17, 
further including: 

computer code that loads a class, the class being associ- 
ated with the function. 2 5 

24. A computer program product for enhancing the execu- 
tion performance of a function at run-time, the computer 
program product comprising: 

computer code that compiles the function at run-time; 
computer code that identifies a call to a process at 30 

run-time, the call to the process being included in the 

function; 

computer code that adds dependency information to the 
function at run-time, wherein the dependency informa- 
tion is arranged to indicate a status of the function, the 



20 



status being arranged to include when a validity status 
of the function; 

computer code that is arranged to load a new class; 

computer code that determines whether the compiled 
version of the function remains valid after a new class 
is loaded based on the dependency information and for 
determining whether the function is suitable for at least 
one of deoptimization and reoptimization when it is 
determined that the compiled version of the function is 
invalid; and 

a computer-readable medium that stores the computer 
codes. 

25. A run-time based computer-implemented method for 
enhancing the execution performance of a function at run- 
time, the computer-implemented method comprising: 

compiling the function at run-time; 

identifying a call to a process at run-time, the call to the 
process being included in the function; 

adding dependency information to the function at run- 
time, wherein the dependency information is arranged 
to indicate a status of the function; 

determining whether the compiled function is valid based 
on the dependency information; and 

determining whether the function is suitable for deopti- 
mization or reoptimization when it is determined that 
the compiled function is invalid. 

26. A computer-implemented method as recited in claim 
25, wherein the dependency information includes class 
information, name information, and signature information 
associated with the process, and wherein the status of the 
function is arranged to indicate a validity of the function and 
a compilation status of the function. 
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